1. Field of the Invention
The present invention relates to assignment of an Internet Protocol (IP) source address for a host device to access a destination via a prescribed multihomed site (e.g., a Virtual Private Network Enterprise) having multiple connections to a wide area network such as the Internet. More particularly, the present invention relates to maintaining secrecy of unique local IPv6 addresses (i.e., in-site addresses), used by in-site IPv6 nodes for communication within a prescribed multihomed site, while communicating with an extra-site destination via the wide area network.
2. Description of the Related Art
A multihomed (or multi-homed) site is a site (e.g., a private local area network or private wide area network) having multiple connections to a wide area network such as the Internet. The term “site” as used herein follows the definition specified in Internet Engineering Task Force (IETF) Request for Comments (RFC) 3582: an entity autonomously operating a network according to Internet Protocol and, in particular, determining the addressing plan and routing policy for that network. This definition of “site” as used herein is equivalent to the term “enterprise” as defined in RFC 1918.
An exemplary multi-homed site is illustrated in commonly-assigned, application Ser. No. 11/198,190, filed Aug. 8, 2005, the disclosure of which is incorporated in its entirety herein by reference.
As described in the above-incorporated application Ser. No. 11/198,190, the multiple connections by the site may be provided by a single Internet Service Provider (ISP) providing multiple links to the public wide area network, or by different ISPs providing respective links to the public wide area network. In addition, the multiple links may be located at separate geographic locations. Advantages to a multi-homed site include improved fault tolerance, load-balancing, etc.
Multi-homing solutions today apply to both IPv4 and IPv6 networks: a site obtains a dedicated block of address space (i.e., a prescribed address prefix) from each ISP, and assuming multiple ISPs are employed, the site advertises the routes for the respective address prefixes via the respective ISP connections. Hence, the site owns address prefixes from each of the ISPs, creating the possibility that a host node in the site sources a packet (i.e., generates a packet) having a source address within the address space of the first ISP (e.g., ISP-A), and causes the packet to be routed via the second ISP (e.g., ISP-B). A disadvantage of advertising multiple prefixes, however, is that it multiplies the number of routes that need to be distributed throughout the “Default Free Zone” (DFZ) between the site and the public wide area network.
The IETF has established a Working Group, entitled the “Site Multihoming in IPv6 (multi6)” Working Group, that addresses technical issues associated with implementing a multi-homed site. As described on the “Multi6” working group web site, publicly available at the web site address “ietf.org/html.charters/multi6-charter.html”, multihoming today is performed largely by a site obtaining a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time.
The Multi6 Working Group has stated on its web page that it will seek alternative approaches with better scaling properties. Additional details regarding the goals for IPv6 site multihoming architectures is described in its RFC 3582. However, the Multi6 Working Group is focusing on host-based solutions, which had the disadvantage of not utilizing network-based management systems that may be able to provide optimized routes based on network conditions and routing protocols.
Another problem that needs to be addressed in the context of multi-homed sites involves the interaction between legacy host devices and ingress filtering by access routers providing a connection between the site and the public wide area network. In particular, a site having two access routers from respective ISPs and that follow source address ingress filtering rules may encounter packets being dropped if the packets do not comply with the source address ingress filtering rules. In other words, an access router may determine from its ingress filtering rules that a packet is not topologically correct because it does not specify a source address that is within the prescribed source address prefix (i.e., address realm) assigned to the access router. For example, the Internet Draft by Huitema et al., “Ingress filtering compatibility for IPv6 multihomed sites” (draft-huitema-multi6-ingress-filtering-00) describes that ingress filtering, normally used to verify the source address of the IP packets in order to prevent denial of service attacks based on using “spoofed” source addresses, actually may cause an access router to drop legitimate packets due to a host device utilizing an IP source address that is within an assigned address prefix of another access router and that is outside the address prefix range of the access router receiving the IP packet. Huitema et al. proposes minimizing ingress filtering conflicts by creating source address dependent (SAD) routing, where routers in the source based routing domain maintained as many parallel routing tables as there are valid source prefixes, causing the packets to exit the site to the appropriate router. Huitema et al. also proposes adding an exit router discovery mechanism within host devices to enable the host device to discover the preferred exit router for a given source address; hence, the host device can tunnel the packet directly to the adequate exit router.
Unfortunately, the source address selection in Huitema et al. is still performed randomly by the host device, and does not address that a given source address may be preferred in certain instances. Moreover, the above-identified Internet Draft by Huitema et al. does not address exploiting the advantage of redundancy in a multi-homing site. Further, the SAD routing proposed by Huitema et al. requires multiple instances of the routing protocol to be executed for respective prefixes; hence, each instance of the routing protocol only will possess knowledge learned through the corresponding ISP associated with the address prefix: if one of the ISPs encounters a failure, the default route will not be advertised by the corresponding exit router, causing routers within the site to remove the default route entry from their default routing tables; however, the multi-homed host device will be unaware of the unavailability of the failed ISP. Hence, a problem arises that a multi-homed host device may continue to send packets using a source address derived from an address prefix that has been assigned by the failed ISP.
Another issue of site multihoming involves deploying a protocol for mobile host devices that are attached to the multihomed site. In particular, IP-level mobility support protocols such as Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) do not provide standardized support for simultaneous differentiated use of multiple access technologies. The IETF has formed the Mobile Nodes and Multiple Interfaces in IPv6 (monami6) Working Group. As described on the “Monami6” working group website, publicly available at the website address “ietf.org/html.charters/monami6-charter.html”, the goal of the Monami6 working group is to address problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc).
Still another concern is safeguarding computers having access to a wide area network (such as the Internet) while preserving network-based services for those computers. Of particular interest is the effort to maintaining the secrecy of an IP address used by a network node.
In particular, efforts are underway to expand the realm of private networks for enterprise applications, where a large private site can be formed based on private (e.g., secure) connections and routes are established between remote nodes. An example of a larger private site is a Virtual Private Network as described in RFC 4364 by Rosen et al., “BGP/MPLS IP Virtual Private Networks (VPNs)”, published February 2006. Rosen et al. describes a method by which an IPv4 Service Provider may use an IP backbone to provide IPv4 VPNs (Virtual Private Networks) for its customers. However, Rosen et al. also suggests in Section 11 (“Accessing the Internet from a VPN”) that private routes would need to be leaked to the global Internet. Consequently, discovery of a private route would enable an untrusted source to analyze an IP address to discover an internal topology of a VPN.
Unfortunately, all nodes within a private network would need to use global source addresses in order to perform any communications with a remote node via a wide area packet switched network such as the Internet. Hence, VPNs cannot be used to hide global source addresses of VPN users.
One approach for hiding global IPv4 source addresses for VPN users has been to deploy Network Address Translators. Network Address Translators (NATs) were originally developed to delay address depletion by reuse of private IPv4 addresses by network nodes in IPv4-based private networks. The NATs, serving as an interface between a private network and the wide area network such as the Internet, would translate between the prescribed IPv4 addresses and a public IPv4 address used by the NAT as a point of attachment to the Internet. In particular, NATs perform a Layer-3 translation of IP addresses, so that public Internet addresses map to private IP addresses, as described in detail by the Request for Comments 1918 (RFC 1918), published by the Internet Engineering Task Force (IETF), available on the World Wide Web at www.ietf.org. This mapping has allowed enterprises to map a large number of private addresses to a limited number of public addresses, thus limiting the number of public addresses required by Internet users.
In addition, the use of NATs in a private IPv4 network enables the private IPv4 address used by a network node to be “hidden” from the Internet, especially since the private IPv4 addresses are reserved by the Internet Assigned Numbers Authority (IANA) exclusively for private networks. Exemplary IPv4 network prefixes reserved by the IANA for private networks include the 10/8 prefix (a single Class A network number), 172.16/12 prefixes (a set of 1 contiguous Class B network numbers), and 192.168/16 prefix addresses (a set of 256 contiguous Class C network numbers).
Hence, NATs enable VPN users to hide their IPv4 source addresses, and therefore the VPN topology from external entities.
Unfortunately, NATs suffer from numerous problems, as described in details in numerous publications by the IETF, including RFC 2993. Consequently, there is doubt that NATs will be developed for Internet Protocol Version 6 (IPv6) as defined in RFC 2460.
Consequently, concerns arise for the need for security in deployment of IPv6 networks, and preventing IPv6 addresses from being distributed beyond a prescribed site. For example, RFC 4193 by Hinden et al., entitled “Unique Local IPv6 Unicast Addresses”, published October 2005, describes an IPv6 unicast address format that is globally unique and intended for local IPv6 communications within-site boundaries, while allowing sites to be combined or privately interconnected.
Although Hinden et al. recognizes that unique local IPv6 unicast addresses could be “leaked” outside the site boundaries onto the Internet, Hinden et al. recommends that border router policies and firewall filtering policies be implemented to prevent the local IPv6 unicast addresses from being sent onto the Internet. Hence, a disadvantage recognized by Hinden et al. is that it is not possible to route local IPv6 prefixes on the global Internet with current routing technology.
The Internet Draft by Van de Velde et al., “IPv6 Network Architecture Protection” <draft-ietf-v6ops-nap-02.txt>, Oct. 22, 2005, describes another example of hiding a network topology for an IPv6 site, but does not address multi-homed sites or non-IPv6 sites.